Many different file systems provide the capability of linking a file into more than one folder. For example, Unix® file systems provide for both hard and soft links. Use of either type of link lets a file in one directory be listed as though it were stored in the other directory as well. Similarly, the many flavors of the Microsoft® Windows® operating system offer shortcuts, which allow a user to access a file (or directory) from locations other than where the file is saved. (Unix is a registered trademark of the Open Group. Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States and other countries.)
FIG. 1 shows an example of how links operate. In FIG. 1, there are two folders: folder 105 and folder 110. Folder 105 includes files 115 and link 120. Folder 110 includes files 125 and 130, and link 135. Link 120 points to file 125, making it appear that file 125 is also stored in folder 105. Link 135 points to file 115, making it appear that file 115 is also stored in folder 110.
There are other software environments, different from file systems, that can provide similar functionality. One such software environment, the relational database, offers users the ability to relate data in the database. For example, a business can track inventory received from suppliers in one table, and inventory sold in a second table, and cross-reference which suppliers supplied the inventory sold to particular customers.
Another software environment that allows users to cross-reference data is the spreadsheet. It is common for spreadsheets to have formulae that reference other cells. As the referenced cells change values, the cells with the formulae change automatically, reflecting the changes in the referenced cells. For example, if a cell has a formula that adds 5 to the value of a referenced cell, if the referenced cell changes from 5 to 10, the cell with the formula automatically changes from 10 to 15.
All three of these software environments share a common feature: one object (be it a directory, table, or cell) is referencing another object (file, table, or cell) stored elsewhere. And all three software environments share a similar problem. In all three software environments, there is no simple way for the referenced object (file, table, or cell) to determine what might be referencing the object. If the referenced file is changed, there is no way to determine which directories are affected by the change. If the referenced table is changed, there is no way to determine what other data might be affected. And if the referenced cell changes, there is no way to determine which other cells will change automatically. The only way to figure out what objects are referencing the referenced object is by watching the system in operation.
If the referenced object is changed, the referencing object might need to change, too. But the unidirectional nature of the references imposes a significant limitation in making this update. For example, in FIG. 1, if file 125 is deleted from folder 110, link 120 remains in folder 105 until someone notices that it points to a non-existent file. Until someone removes link 120, folder 105 continues to look as though file 125 is still accessible. Or, if file 125 is renamed, folder 105 might not reflect the change of name to file 125. Instead, folder 105 displays the name of link 120, which is not affected by the fact that file 125 is renamed.
A need remains for a way to provide for associations between files and folders that addresses these and other problems associated with the prior art.